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(54) Web-based enterprise management with multiple repository capability 



(57) A transport neutral technique allows an object 
manager (20) to communicate with a CIM repository 
(1 30) using any of a variety of protocols (1 58, 1 60). The 
object manager software (20) is independent of the 
transport mechanism used and need not be changed if 
the transport mechanism changes. A computer system 
(110) to be managed includes a CIM object manager 
(20) and any number of provider APIs (1 22) that provide 
resource information about the computer system. A CIM 
repository (130) stores classes and instances used by 
the object manager. A remote application computer 
(150) runs a software management application (32) that 
communicates with the object manager of the computer 
system using a local client API (156). A Repository API 
of the object manager includes an interface definition 
(300) defining all methods called by the object manager. 
Also included is a protocol-specific class that imple- 
ments the interface definition; there is a protocol-spe- 
cific class for each protocol desired to be supported. 
Each class implements methods using a specific proto- 
col. A factory class is executed when the object man- 
ager invokes a method call passing in a desired protocol 
parameter. The factory class creates a protocol-specific 
object of one of the protocol-specific classes depending 
on the protocol parameter. The object is returned to the 
object manager which executes one of its protocol-spe- 
cific methods thus allowing communication to a reposi- 
tory using a protocol independent of the object 
manager. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to 
managing the resources of a computer system. More 
specifically, the present invention relates to a technique 
for communicating database operations from a Com- 
mon Information Model (CIM) object manager to multi- 
ple remote CIM repositories. 

BACKGROUND OF THE INVENTION 

[0002] Recently, computers and their associated 
peripheral equipment (a computer system) have 
become increasing more complex. As such, it has 
become progressively more and more complicated for a 
user or system administrator to manage the resources 
of such a computer system. With a variety of peripheral 
devices and software applications available for use, and 
their ever-changing nature, the job of a system adminis- 
trator has become more difficult. Computer system 
resources such as attached devices, network connec- 
tions, software applications, etc., must all be managed 
to ensure an efficiently working system for the user. 
Within a large corporation having large numbers of such 
computer systems spread around the world, the task of 
managing the resources of each computer system can 
be daunting. 

[0003] Recently, the industry has responded to 
such a need by introducing Web-Based Enterprises 
Management (WBEM) which is both an initiative and a 
technology. As an initiative, WBEM includes a standard 
for managing systems, networks, users, and applica- 
tions by using Internet technology. As a technology, 
WBEM provides a way for management applications to 
share management data independently of vendor, pro- 
tocol, operating system, or management standard. By 
developing management applications according to 
WBEM principles, vendors can develop products that 
work together easily at a lower cost of development. 
[0004] One known standard for implementation of 
WBEM is the Common Information Model (CIM). CIM is 
an approach to managing systems and networks. CIM 
provides a common conceptual framework to classify 
and define the parts of a network environment and 
depict how they integrate. The model captures notions 
that are applicable to all areas of management, inde- 
pendent of technology implementation. 
[0005] WBEM software includes tools and technol- 
ogy that software developers can use to create CIM- 
compliant software applications that manage the envi- 
ronment of a computer system. Developers can also 
use this software to write "providers," programs that 
supply data and events for managed objects that are 
specific to their domain. 

[0006] There can be drawbacks, however, associ- 
ated with various implementations of WBEM software. 



For example, it may be necessary for the object man- 
ager of a computer system to be able to access different 
types of databases, whether local or remote. Not all 
implementations, however, are well-suited for this type 
5 of access. 

[0007] FIG. 1 illustrates a prior art computer system 
10 that has resources to be managed. Resources 
include disk usage, CPU utilization, running applica- 
tions, etc. Not shown for simplicity are hardware compo- 
te nents of the computer system or other software 
applications. A CIM object manager 20 is responsible 
for handling all communication between management 
applications, a CIM repository 26 and managed objects. 
In this example, CIM repository 26 is a local drive that 
15 communicates via a local connection 28 to object man- 
ager 20. A provider application programming interface 
(API) 22 provides an interface to any needed system 
information 24 to be provided to object manager 20. 
Object manager 20 may also access CIM repository 26 
20 over local connection 28 to quickly retrieve data objects 
that have been previously stored. In this fashion, object 
manager 20 is well-suited for gathering resource infor- 
mation regarding computer system 10. 
[0008] In order to efficiently manage the resources 
25 of computer system 1 0, a software developer 30 writes 
management application software 32 for managing the 
resources of the computer system. When in operation, 
the results of management application 32 may be used 
by a system administrator 40 to manage the computer 
30 system. Client application 32 communicates via a Client 
API 34 to retrieve resource information from computer 
system 10. Client API 34 uses any suitable local or 
remote network connection 36 to access object man- 
ager 20. 

35 [0009] Prior art implementations of this sort use a 
single protocol for communication from object manager 
20 to CIM repository 26 over local connection 28. Such 
an implementation is inflexible in that the object man- 
ager commands to repository 26 are dependent upon a 

40 single protocol. In other words, the commands are not 
independent of the protocol; should the protocol be 
modified or if another protocol be used or desired, it will 
be necessary to rewrite portions of object manager 20 
which would be undesirable. 

45 [0010] In addition, having an object manager that is 
depended upon a particular protocol presents difficul- 
ties when repository 26 is remote from object manager 
20. In this scenario, it may be desirable to communicate 
over a network connection using any of a variety of pro- 

50 tocols instead of always being required to use a local 
protocol. In prior art computer system 10 portions of 
object manager 20 would have to be rewritten for each 
and every different protocol that is desired to be used. 
[001 1 ] Therefore, a technique is desired that would 

55 permit an object manager to communicate both locally 
and remotely with any number of repositories using any 
of a variety of protocols. It is desired to implement this 
technique with the least impact upon developers of 
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object manager software. 
SUMMARY OF THE INVENTION 

[0012] To achieve the foregoing, and in accordance 
with the purpose of the present invention, a technique is 
disclosed that allows an object manager to communi- 
cate with any number of repositories using any of a vari- 
ety of local or remote protocols. Advantageously, the 
object manager becomes independent of protocol used 
and need not be changed if the protocol changes. 
[0013] In one embodiment, a method is used for 
communication between a Common Information Model 
(CIM) object manager and a CIM repository. The 
method involves first creating a connection between the 
object manager the CIM repository. Next, a protocol 
indicator is passed from the object manager to a repos- 
itory API. The protocol indicator identifies a protocol by 
which the object manager desires to communicate with 
the CIM repository. A protocol-specific object is created 
having methods implemented using the protocol. 
Finally, the protocol-specific object is returned to the 
object manager, thus the object manager may commu- 
nicate with the CIM repository using the protocol 
desired. 

[0014] In another embodiment, a computer system 
interacts with a CIM repository on a separate computer. 
The computer system includes an object manager that 
has program code for interacting with the CIM reposi- 
tory and a protocol indicator. Also included is a reposi- 
tory application programming interface (repository API) 
that has a factory class arranged to receive the protocol 
indicator from the object manager and produce a proto- 
col-specific object. Also within the repository API is a 
first class having methods defined thereon implemented 
in a first protocol and a second class having methods 
defined thereon implemented in a second protocol. 
Thus, the protocol-specific object may be returned to 
the object manager for use in communicating with the 
CIM repository using a desired protocol. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0015] The invention, together with further advan- 
tages thereof, may best be understood by reference to 
the following description taken in conjunction with the 
accompanying drawings in which: 

FIG. 1 illustrates a prior art computer system that 
has managed resources. 

FIGS. 2A and 2B illustrate a Web-Based Enterprise 
Management (WBEM) architecture suitable for 
implementing an embodiment of the invention. 

FIGS. 3A and 3B illustrate an example graphical 
user interface for the CIM workshop of FIG. 2. 



FIG. 4 illustrates an interface definition useful for 
implementing an embodiment of the invention. 

FIG. 5 illustrates an implementation definition for 
5 the interface of FIG. 4. 

FIG. 6 illustrates another implementation definition 
for the interface of FIG. 4. 

10 FIG. 7 is a JAVA factory class definition. 

FIG. 8 is a flowchart illustrating a store or retrieve 
repository method issued by an object manager to 
a CIM repository. 

15 

FIGS. 9 and 10 illustrate a computer system suita- 
ble for implementing embodiments of the present 
invention. 



[0016] FIGS. 2A and 2B illustrate a Web-Based 
Enterprise Management (WBEM) architecture suitable 
for implementing an embodiment of the invention. Archi- 

25 tecture 100 includes computer system 110 having 
resources to be managed, and application computer 
150 where management applications are developed 
and run. Computer system 110 may be any suitable 
computer having resources needing to be managed 

30 such as CPU load, disk space, installed applications, 
etc. The hardware layer includes workstation 112 and 
CPU 1 14. Workstation 112 may be any suitable compu- 
ter workstation such as the SPARC workstation from 
Sun Microsystems, Inc. CPU 114 may be any suitable 

35 processor such as an Intel processor. The software 
layer of computer system 110 includes operating sys- 
tem 1 1 6 (other software applications not shown for sim- 
plicity) which may be any suitable operating system 
such as the Solaris operating system from Sun Micro- 

40 systems, Inc. 

[0017] The object provider layer of computer sys- 
tem 110 includes operating system provider 118, oper- 
ating system services 120 and provider application 
programming interface (API) 122. The provider layer 

45 communicates with operating system 116 via interface 
117, for example, by using a JAVA Native Interface 
(JNI). Object providers act as intermediaries between 
CIM object manager 20 and one or more managed 
devices. When object manager 20 receives a request 

so from a management application 32 for data that is not 
available in CIM repository 130 it forwards the request 
to a provider. Object providers are installed on the same 
machine as object manager 20. Object manager 20 
then uses provider API 122 to communicate with locally 

55 installed providers. Providers are classes that perform 
various functions in response to a request from object 
manager 20. For example, providers map information 
from a managed device to a CIM JAVA class and map 
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information from a CIM JAVA class to a managed device 
format. 

[0018] Provider API 122 is an API used by various 
provider programs to communicate information about 
managed objects to object manager 20. Operating sys- 
tem provider 118 is a collection of JAVA classes or 
native methods that represent the operating environ- 
ment of computer system 110. Operating system serv- 
ices 120 also provide logging information from 
operating system 1 16 to object manager 20. 
[0019] A variety of other providers may also be 
present. For example, an SNMP provider includes JAVA 
classes that map CIM data to SNMP data. Also, a CPU- 
specific provider may be used to transport resource 
information directly between CPU 1 1 4 and provider API 
122, thus bypassing operating system 1 16. 
[0020] Providers may be categorized into three 
types according to the requests they service. An 
instance type supplies dynamic instances of a given 
class and supports the retrieval, enumeration, modifica- 
tion and deletion operations. A property type supplies 
dynamic property values, for example, disk space. A 
method type supplies methods of one or more classes. 
A single provider can support both methods and 
instances. Most providers are "pull" providers which 
mean they maintain their own data, generating it 
dynamical if necessary. Pull providers have minimal 
interaction with object manager 20 and CIM repository 
130. The data managed by a pull provider typically 
changes frequently, requiring the provider to either gen- 
erate the data dynamically or retrieve it from a local 
cache whenever an application issues a request. A sin- 
gle provider can act simultaneously as a class instance 
and method provider by proper registration and imple- 
mentation of all relevant methods. 
[0021] The management layer of computer system 
110 includes CIM object manager 20, CIM repository 
130 and web server software 140. Object manager 20 
may be any suitable WBEM compliant manager. Object 
manager 20 manages CIM objects that are represented 
internally as JAVA classes. Client computers running 
management applications (such as application compu- 
ter 150) connect to object manager 20 for resource 
information about computer system 110. When a 
WBEM client connects to object manager 20 it receives 
a reference to that object manager. The client can then 
perform WBEM operations using this reference. 
[0022] When management application 32 uses cli- 
ent API 156 to request or update information about a 
managed object, object manager 20 contacts either the 
appropriate provider for that object or a suitable persist- 
ent storage mechanism such as repository 130. In one 
embodiment, classes that are handled by a provider 
have a "provider" qualifier that identifies the provider to 
contact for the class. When object manager 20 receives 
a request for a class that has a "provider" qualifier, it 
routes the request to the specified provider. If no pro- 
vider is specified it routes the request to repository 130 



using JAVA Naming and Directory Interface (JNDI) 132. 
[0023] Object manager 20 also performs various 
start-up functions: starting and registering the RMI 
server; registering the XML server; setting up a connec- 

5 tion to repository 130; and waiting for incoming 
requests. Object manager 20 also performs other nor- 
mal operations: performing security checks such as 
authentication and authorization; performing syntactical 
and semantic checking of CIM data operations; routing 

w requests to providers or persistent storage; and deliver- 
ing data from providers or from persistent storage to cli- 
ent management applications. 

[0024] CIM repository 130 is a central storage area 
for CIM class and instance definitions that communi- 

15 cates with object manager 20 via connection 132. Con- 
nection 132 may be any suitable local connection within 
computer system 110, or may be a remote connection. 
Connection 132 may use any suitable protocol. Further 
details on communication with repository 130 are pro- 

20 vided in FIG. 2B and in FIGS. 4-8. 

[0025] Web server software 140 may be any suita- 
ble WBEM XML-compliant web server such as the Sun 
Web Server available from Sun Microsystems, Inc. 
JAVA servlet 142 converts XML data to the client API 

25 format. For example, if management application 132 
contains XML data, client API client 156 encodes the 
data as XML messages and transports the encoded 
messages to web server 140 that is running JAVA serv- 
let 1 42. Web server 1 40 listens for XML messages on a 

30 standard port and passes control to servlet 142 when 
detected. Servlet 142 then decodes the XML messages 
it receives. Servlet 142 then converts the XML data to 
the client API format and transmits the information back 
to client API 156 in RMI format. Alternatively, should 

35 object manager 20 support the HTTP format, client API 
156 may communicate directly to object manager 20 
without the need for web server 1 40. 
[0026] The application layer of WBEM architecture 
100 includes management application 32, CIM work- 

40 shop 152, MOF compiler 154 and client application pro- 
gramming interface (API) 156. In this embodiment of the 
invention, these elements of the application layer are 
shown running on application computer 150 (other 
hardware and software not shown for simplicity). Alter- 

45 natively, application computer 150 and computer sys- 
tem 1 1 0 may be the same computer or the elements of 
the application layer may reside on a variety of comput- 
ers and not exclusively on application computer 150. 
[0027] A software developer 30 uses any suitable 

50 software tool to develop a management application 32 
for processing and displaying data from managed 
objects of computer system 110. Management applica- 
tion 32 uses client API 156 to request information about 
managed objects from object manager 20. In this fash- 

55 ion, analysis of the resources of computer system 110 
can be presented to a system administrator 40 for 
proper action. 

[0028] Client API 156 and provider APIs represent 
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and manipulate CIM objects. These APIs represent CIM 
objects as JAVA classes. An object is a computer repre- 
sentation or model of a managed resource of computer 
system 110 such as a printer, disk drive or CPU. A 
developer uses the CIM specification to describe man- 
aged objects and to retrieve information about managed 
objects in computer system 110. One advantage of 
modeling managed resources using CIM is that those 
objects can be shared across any system that is CIM 
compliant. 

[0029] Management application 32 may be any of a 
wide variety of software applications written to analyze 
and manage the resources of computer system 1 1 0. By 
way of example, management application 32 manages 
system aspects such as disk information (space availa- 
ble, partitions, etc.), CPU load, event processing, date, 
time, time zone, memory available, ports, etc. 
[0030] Application 32 may also manage specific 
devices of the computer system such as disks, tape 
drives, modems, other I/O devices, NICs, and network 
aspects of the system such as TCP/IP, Netbeui, Novell, 
etc. Further, management application 32 manages the 
software applications running on computer system 1 10 
by determining what is currently running on the system, 
what is currently installed, the state of installation, which 
applications can be terminated, performing application 
metering, managing application life cycle, process man- 
agement, user management, etc. 

[0031] In one embodiment of the invention, devel- 
oper 30 uses a CIM workshop 152 written in JAVA for 
viewing, changing, adding and deleting CIM classes 
and instances. CIM workshop 152 provides a graphical 
user interface for the developer. For example, developer 
30 may view and select namespaces, may add name- 
spaces, add properties, qualifiers and methods to new 
classes, view and create instances, and view and mod- 
ify instance values. Developer 30 may also use CIM 
workshop 152 to browse a class inheritance tree and 
change the root of an object tree for a namespace. 
[0032] MOF compiler 154 pares files created in the 
Managed Object Format (MOF), converts files to JAVA 
class and stores the extracted classes and instances in 
repository 1 30. The MOF language is a syntax for defin- 
ing CIM classes and instances and is described in the 
CIM specification. Although classes and instances can 
also be added through client API 156 using JAVA, MOF 
compiler 154 eliminates the need to write such code. 
Compiler 154 provides developers and administrators 
with a simple and fast technique for modifying reposi- 
tory 130. 

[0033] In one embodiment, client API 156 is a pub- 
lic API that JAVA applications use to request operations 
from object manager 20. Client API 1 56 is used by man- 
agement application 32 to transfer data to and from 
object manager 20. Client API 156 includes a variety of 
classes, instances and methods useful for communicat- 
ing with object manager 20 using any suitable transport 
mechanism. 



[0034] Preferably, Client API 156 is an application 
programming interface used by management applica- 
tion 32 to communicate with object manager 20 using 
Remote Method Invocation (RMI) protocol 158 or XML 

5 over an HTTP protocol 160 according to the techniques 
described in U.S. patent application No. 
(Atty Docket SUN1P366) refer- 
enced above. Other suitable protocols may also be used 
such as COM from Microsoft Corporation. Client API 

10 156 may communicate directly with object manager 20 
using RMI or may communicate using the XML/HTTP 
protocol using web server 140. Alternatively, client API 
156 can communicate using the XML/HTTP protocol 
160 directly should object manager 20 support the 

75 HTTP format. 

[0035] Connections 170a-170d are any suitable 
local or network connection between computer system 
1 10 and application computer 150. By way of example, 
these connections occur over an internet, an intranet, 

20 an extranet, within a workgroup, or other. 

[0036] FIG. 2B illustrates further detail in which CIM 
object manager 20 communicates with any of a variety 
of remote CIM repositories using a repository API 180. 
In this embodiment, each of repositories 190, 192 and 

25 1 94 are located remotely from object manager 20 and 
computer system 110. In this example each repository 
is located on a different computer although it is conceiv- 
able that all may be located on a single computer, or 
that a repository is local to computer system 110. 

30 [0037] Repository 190 is a database implemented 
using a flat file technique or object serialization in JAVA; 
it communicates with Repository API 180 over a net- 
work connection 132a that uses simple JAVA code pro- 
tocol. Repository 192 is an object-oriented database 

35 and may be implemented using tools such as those 
available from Sybase, Oracle, or Informix. Repository 
812 communicates with Repository API 180 over a net- 
work connection 132b using a JAVA Database Connec- 
tivity (JDBC) protocol. Repository 194 is a Lightweight 

40 Directory Access Protocol (LDAP) type of database that 
communicates over network connection 132c using a 
JAVA Naming Directory Interface (JNDI) protocol. 
[0038] Repository API 180 is used by object man- 
ager 20 to store data to, or retrieve data from, the repos- 

45 itories. Repository API 1 80 includes a variety of classes, 
instances and methods useful for communicating with 
the repositories using any suitable protocol. Preferably, 
Repository API 180 communicates with the repositories 
using a JAVA language protocol, a JDBC protocol, a 

so JNDI protocol, an LDAP protocol, an ODBC protocol, or 
other protocols suitable for use with a database. Imple- 
mentation of such communication between object man- 
ager 20 and the repositories according to an 
embodiment of the invention is further described in 

55 FIGS. 4-8. 

[0039] FIGS. 3A and 3B illustrate an example 
graphical user interface for CIM workshop 152. Prefera- 
bly, a login to the workshop prompts for a host name, 
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namespace, user name and password. By default, 
workshop 152 connects to the object manager on the 
local host in the default namespace. FIG. 3A illustrates 
CIM classes that represent objects in the selected 
namespace on the selected host. Listed in panel 210 5 
are the objects of the selected namespace. On the right- 
hand panel are shown the properties 212 for the 
selected object (in this case the object "Solaris Pack- 
age") and methods 214 (not shown). FIG. 3B shows all 
instances of a selected object. Instances are shown in w 
the left-hand panel, and in this example instance 252 is 
shown. The right-hand panel shows all properties 254 
associated with the selected instance and its associated 
methods 256 (not shown). 

[0040] FIG. 4 illustrates an interface definition 300 15 
of Repository API 180 useful for implementing an 
embodiment of the invention. Interface 300 lists various 
methods that may be called by object manager 20 in the 
course of database operations with repositories 190- 
194. Advantageously, this interface may be imple- 20 
mented using a variety of classes having protocol-spe- 
cific methods thus allowing a transport neutral object 
manager to be written. Interface 300 includes an inter- 
face name 302 which in this example is "CIM Repository 
API." Included are a variety of methods defined for the 25 
interface. Each method has a method name 304, a 
return value 306 and parameters 308. By way of exam- 
ple, shown is one method "Add CIM Element" 310 hav- 
ing a return value of "void" and accepting parameters 
"element" and "namespace." A large number of other 30 
methods may be defined for interface 300 
[0041] By way of example, these methods include 
the following. The Create Namespace method creates a 
CIM namespace, a directory containing classes and 
instances. (When a management application connects 35 
to object manager 20 it specifies a namespace. All sub- 
sequent operations occur within that namespace on the 
object manager host.) The method Delete Class deletes 
the specified class. The method Delete Instance deletes 
the specified instance. The method Delete Qualifier 40 
deletes the specified qualifier. The method Enumerate 
Classes retrieves the specified classes from a reposi- 
tory. The method Enumerate Namespace gets a list of 
namespaces. The method Enumerate Instances gets of 
list of instances for the specified class. The method 45 
Enumerate Qualifier Types get a list of qualifier types for 
the specified class. The method Get Class gets the CIM 
class for the specified CIM object path. The Get 
Instance method gets the CIM instance for the specified 
CIM object path. so 
[0042] The method Get Qualifier Type gets the 
qualifier type for the specified CIM object path. The 
method Set Instance invokes a repository to add or 
update the specified CIM instance to the specified 
namespace. Other methods may also be included 55 
within interface 300 such as Add Aliased Class Name, 
Add Aliased Instance Name, Get Aliased Class Name, 
Get Aliased Instance Name, etc. 



[0043] Once interface 300 has been defined it is 
possible to then code protocol-specific methods to 
implement each of the methods defined in interface 
300. In this fashion, any number of protocol-specific 
classes are provided each having an implementation for 
a specific protocol such as JDBC or LDAP. Though the 
use of these protocol-specific classes, object manager 
20 is able to communicate with any CIM repository 
using any suitable protocol in a transparent fashion. 
[0044] FIG. 5 illustrates an implementation defini- 
tion 400 for the interface of FIG. 4. Specifically, imple- 
mentation 400 implements class "CIM Repository API" 
using methods specific to the LDAP protocol. Such pro- 
tocol-specific methods allow object manager 20 to com- 
municate via Repository API 180 to repository 194 
using the LDAP protocol. Implementation 400 includes 
a class name 402 "CIM Repository LDAP." Also 
included is constructor definition code 404 that con- 
structs an instance of class 402 that is specific to the 
LDAP protocol. Use of a constructor definition to create 
an instance is well known to those of skill in the art. 
[0045] Also included in implementation 400 are the 
specific implementations of the methods defined upon 
interface 300. For each method implemented there is a 
method name 406, a return value 408, parameters 410 
and implementation code 412. Implementation code 
412 is preferably JAVA code that implements the partic- 
ular method using any constructs necessary that are 
specific to the RMI protocol. Those of skill in the art will 
appreciate how to implement JAVA code for a particular 
purpose that must adhere to a specific protocol. 
[0046] Preferable, all of the methods defined upon 
interface 300 are implemented in implementation 400. 
Shown by way of example is the method Add CIM Ele- 
ment 416 which has a return value of "void" and accepts 
the parameters element and namespace. Not shown for 
simplicity is the actual LDAP-specific JAVA code that 
implements the method Add CIM Element. The other 
methods defined in interface 300 are also listed in 
implementation 400 along with their LDAP-specific 
code. 

[0047] FIG. 6 illustrates an implementation defini- 
tion 500 for the interface of FIG. 4. Specifically, imple- 
mentation 500 implements class "CIM Repository API" 
using methods specific to the JDBC protocol. Such pro- 
tocol-specific methods allow object manager 20 to com- 
municate via Repository API 180 to repository 192 
using the JDBC protocol. Implementation 500 includes 
a class name 502 "CIM Repository JDBC." Also 
included is constructor definition code 504 that con- 
structs an instance of class 502 that is specific to the 
JDBC protocol. Use of a constructor definition to create 
an instance is well known to those of skill in the art. 
[0048] Also included in implementation 500 are the 
specific implementations of the methods defined upon 
interface 300. For each method implemented there is a 
method name 506, a return value 508, parameters 510 
and implementation code 512. Implementation code 
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512 is preferably JAVA code that implements the partic- 
ular method using any constructs necessary that are 
specific to the JDBC protocol. Those of skill in the art 
will appreciate how to implement JAVA code for a partic- 
ular purpose that must adhere to a specific protocol. 
[0049] Preferable, all of the methods defined upon 
interface 300 are implemented in implementation 500. 
Shown by way of example is the method Add CIM Ele- 
ment 51 6 which has a return value of "void" and accepts 
the parameters element and namespace. Not shown for 
simplicity is the actual JDBC-specific JAVA code that 
implements the method Add CIM Element. The other 
methods defined in interface 300 are also listed in 
implementation 500 along with their JDBC-specific 
code. 

[0050] FIG. 7 is a JAVA factory class 600. Factory 
600 is used for determining which protocol is desired by 
object manager 20 and directing the creation of a proto- 
col-specific object to be returned to the object manager. 
[0051] Factory 600 includes a class name 602 "CIM 
Repository Factory" and any number of defined meth- 
ods. For each method there is a method name 604, a 
return value 606, parameters 608 and an implementa- 
tion 610. In particular, the method Get Repository API 
accepts the parameters protocol, namespace and ver- 
sion, and returns an instance of interface 300 which is a 
protocol-specific instance of either implementation 400 
or implementation 500. Of course, other protocol-spe- 
cific objects may be returned if other implementations 
are defined. The implementation code 610 for method 
612 may be any suitable JAVA code that checks the pro- 
tocol parameter to see which protocol is desired and 
then directs either implementation 400 or 500 to con- 
struct a new instance of itself. By way of example, a 
series of case statements may be used. Other methods 
may also be defined and implemented within factory 
600. 

OBJECT MANAGER EXECUTION 

[0052] FIG. 8 is a flowchart illustrating invocation of 
a method by the object manager to perform a database 
operation such as storing or retrieving an object. Once 
management application 32 has been created by devel- 
oper 30 and the classes and methods of FIGS. 4-7 have 
been defined, the object manager may perform opera- 
tions on one of the repositories using any desired proto- 
col. FIG. 8 illustrates a single method call according to 
one embodiment of the invention. 
[0053] In step 702 management application 32 cre- 
ates a connection from application computer 150 to 
computer system 110. Preferably, application 32 
invokes a method within Client API 156 which creates 
an instance of application 32 within object manager 20. 
Application 32 passes to the method a host name, a 
namespace, a user name, a password, and the protocol 
by which it is desired to communicate with host compu- 
ter system 110. Any suitable network protocol may be 



identified such as RMI, XML/HTTP or DCOM. 
[0054] In step 704 object manager 20 receives a 
method call from application 32 that requires a data- 
base operation. The method call is preferably performed 

5 using the technique described in U.S. patent application 
No. 09/333,878. In response to this method call, object 
manager 20 identifies a repository and protocol and 
makes a call to Repository API 180. 
[0055] In step 706 factory 600 of Repository API 

10 180 checks the protocol desired by object manager 20 
using its method Get Repository API. This method 
returns a protocol-specific object which is an instance of 
either the class defined in implementation 400 or the 
class defined in implementation 500. For example, in 

15 step 710 if the protocol parameter is LDAP, then in step 
714 the constructor definition 404 of implementation 
400 executes and results in an LDAP-specific object 
having LDAP-specific methods being returned to the 
object manager. On the other hand, if the protocol 

20 parameter is JDBC, then in step 722 the constructor 
definition 504 of implementation 500 executes and pro- 
duces a JDBC-specific object which is returned to the 
object manager. As shown in steps 726 and 730, a 
desire for use of simple JAVA protocol results in a JAVA- 

25 specific object being returned. Other protocols are also 
supported. In step 738 object manager 20 invokes a 
desired database method upon the protocol-specific 
object recently returned. Because the methods of this 
object are specific to the protocol desired by object 

30 manager 20, communication between Repository API 
180 and the target repository occurs using the desired 
protocol in a fashion transparent to application 32 and to 
object manager 20. 

[0056] Once the target CIM repository has proc- 
35 essed the method (which may be a request for an 
object, a request to add an object, etc.), then in step 742 
the result is returned from the repository to object man- 
ager 20 via Repository API 1 80 using the desired proto- 
col. In this fashion, a technique has been described that 
40 allows an object manager to be written independent of 
the protocol by which it is desired to communicate with 
a target CIM repository. 

COMPUTER SYSTEM EMBODIMENT 

45 

[0057] FIGS. 9 and 10 illustrate a computer system 
900 suitable for implementing embodiments of the 
present invention. FIG. 9 shows one possible physical 
form of the computer system. Of course, the computer 

so system may have many physical forms ranging from an 
integrated circuit, a printed circuit board and a small 
handheld device up to a huge super computer. Compu- 
ter system 900 includes a monitor 902, a display 904, a 
housing 906, a disk drive 908, a keyboard 910 and a 

55 mouse 912. Disk 914 is a computer-readable medium 
used to transfer data to and from computer system 900. 
[0058] FIG. 1 0 is an example of a block diagram for 
computer system 900. Attached to system bus 920 are 
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a wide variety of subsystems. Processor(s) 922 (also 
referred to as central processing units, or CPUs) are 
coupled to storage devices including memory 924. 
Memory 924 includes random access memory (RAM) 
and read-only memory (ROM). As is well known in the 
art, ROM acts to transfer data and instructions uni- 
directionally to the CPU and RAM is used typically to 
transfer data and instructions in a bi-directional manner. 
Both of these types of memories may include any suita- 
ble of the computer-readable media described below. A 
fixed disk 926 is also coupled bi-directionally to CPU 
922; it provides additional data storage capacity and 
may also include any of the computer-readable media 
described below. Fixed disk 926 may be used to store 
programs, data and the like and is typically a secondary 
storage medium (such as a hard disk) that is slower 
than primary storage. It will be appreciated that the 
information retained within fixed disk 926, may, in appro- 
priate cases, be incorporated in standard fashion as vir- 
tual memory in memory 924. Removable disk 914 may 
take the form of any of the computer-readable media 
described below. 

[0059] CPU 922 is also coupled to a variety of 
input/output devices such as display 904, keyboard 91 0, 
mouse 912 and speakers 930. In general, an input/out- 
put device may be any of: video displays, track balls, 
mice, keyboards, microphones, touch-sensitive dis- 
plays, transducer card readers, magnetic or paper tape 
readers, tablets, styluses, voice or handwriting recog- 
nizers, biometrics readers, or other computers. CPU 
922 optionally may be coupled to another computer or 
telecommunications network using network interface 
940. With such a network interface, it is contemplated 
that the CPU might receive information from the net- 
work, or might output information to the network in the 
course of performing the above-described method 
steps. Furthermore, method embodiments of the 
present invention may execute solely upon CPU 922 or 
may execute over a network such as the Internet in con- 
junction with a remote CPU that shares a portion of the 
processing. 

[0060] In addition, embodiments of the present 
invention further relate to computer storage products 
with a computer-readable medium that have computer 
code thereon for performing various computer-imple- 
mented operations. The media and computer code may 
be those specially designed and constructed for the pur- 
poses of the present invention, or they may be of the 
kind well known and available to those having skill in the 
computer software arts. Examples of computer-reada- 
ble media include, but are not limited to: magnetic 
media such as hard disks, floppy disks, and magnetic 
tape; optical media such as CD-ROMs and holographic 
devices; magneto-optical media such as floptical disks; 
and hardware devices that are specially configured to 
store and execute program code, such as application- 
specific integrated circuits (ASICs), programmable logic 
devices (PLDs) and ROM and RAM devices. Examples 



of computer code include machine code, such as pro- 
duced by a compiler, and files containing higher level 
code that are executed by a computer using an inter- 
preter. 

5 [0061] Although the foregoing invention has been 
described in some detail for purposes of clarity of 
understanding, it will be apparent that certain changes 
and modifications may be practiced within the scope of 
the appended claims. For instance, the application com- 

w puter and the computer system to be managed may be 
the same computer, or may be separated by a great dis- 
tance. Also, the various CIM repositories may be 
located along with the computer system, may each be 
remotely located on a separate computer, or may be 

15 remotely located on a single computer. The use of a 
web server may not be required should the CIM object 
manager support the HTTP format. Other types of 
classes and methods may be used while not departing 
from the spirit of the invention. Therefore, the described 

20 embodiments should be taken as illustrative and not 
restrictive, and the invention should not be limited to the 
details given herein but should be defined by the follow- 
ing claims and their full scope of equivalents. 



1. A method for communication between a Common 
Information Model (CIM) object manager of a host 
computer and a CIM repository, said method com- 
30 prising: 

creating a connection between said object 
manager and said CIM repository; 

35 passing a protocol indicator from said object 

manager to a repository application program- 
ming (API), said protocol indicator identifying a 
protocol by which said CIM object manager 
desires to communicate with said CIM reposi- 

40 tory; 

creating a protocol-specific object having meth- 
ods implemented using said protocol; and 

45 returning said protocol-specific object to said 

CIM object manager, whereby said CIM object 
manager may communicate with said CIM 
repository using said protocol. 

50 2. The method of claim 1 further comprising: 

invoking a method defined upon said protocol- 
specific object; 

55 transmitting said method using said protocol 

over said connection to said CIM repository; 
and 
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returning a result to said CIM object manager 
over said connection using said protocol. 

3. The method of claim 1 wherein said protocol is 
LDAR JDBC, or JAVA. 5 

4. The method of claim 1 wherein said CIM repository 
is resident on said host computer. 

5. The method of claim 1 wherein said CIM repository 10 
is resident on a separate computer. 

6. The method of claim 1 wherein said creating a pro- 
tocol-specific object includes 

15 

calling a JAVA factory class. 

7. A computer system for interacting with a CIM 
repository database, said system comprising: 

20 

a CIM object manager including a protocol indi- 
cator and program code for interacting with 
said CIM repository; and 



8. The system of claim 7 wherein said CIM object 
manager is arranged to receive a method call from 
a management application using the protocol iden- 
tified by said protocol indicator. 45 

9. The system of claim 7 wherein said CIM repository 
is resident on said computer system. 

10. The system of claim 7 wherein said computer sys- so 
tern and said CIM repository are connected over a 
network connection implemented in the protocol 
identified by said protocol indicator. 

11. The system of claim 7 wherein the protocol identi- 55 
fied by said protocol indicator is LDAP, JDBC or 
JAVA. 



12. The system of claim 7 further comprising: 

a plurality of CIM repositories, each repository 
arranged to communicate with said CIM object 
manager using a different protocol. 

13. The system of claim 12 wherein each repository is 
resident on a different computer. 

14. A computer-readable medium comprising computer 
code for communication between a Common Infor- 
mation Model (CIM) object manager of a host com- 
puter and a CIM repository, said computer code of 
said computer-readable medium effecting the fol- 
lowing: 

creating a connection between said object 
manager and said CIM repository; 

passing a protocol indicator from said object 
manager to a repository application program- 
ming (API), said protocol indicator identifying a 
protocol by which said CIM object manager 
desires to communicate with said CIM reposi- 
tory; 

creating a protocol-specific object having meth- 
ods implemented using said protocol; and 

returning said protocol-specific object to said 
CIM object manager, whereby said CIM object 
manager may communicate with said CIM 
repository using said protocol. 

15. The computer-readable medium of claim 14 further 
comprising computer code for effecting the follow- 
ing: 

invoking a method defined upon said protocol- 
specific object; 

transmitting said method using said protocol 
over said connection to said CIM repository; 
and 

returning a result to said CIM object manager 
over said connection using said protocol. 

16. The computer-readable medium of claim 14 
wherein said protocol is LDAP, JDBC or JAVA. 

17. The computer-readable medium of claim 14 
wherein said creating a protocol-specific object 
includes 

calling a JAVA factory class. 



a repository application programming interface 25 
(repository API) including 

a factory class arranged to receive said 
protocol indicator from said object man- 
ager and produce a protocol-specific 30 
object, 

a first class having methods defined ther- 
eon implemented in a first protocol, and 

35 

a second class having methods defined 
thereon implemented in a second protocol, 
whereby said protocol-specific object may 
be returned to said object manager for use 
in interacting with said CIM repository. 40 
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